---
id: unittest
title: 36.1 单元测试
sidebar_label: 36.1 单元测试
---

## 36.1.1 关于单元测试

引用自百度百科：

> 单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如 C 语言中单元指一个函数，Java 里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

## 36.1.2 单元测试好处

- **消灭低级错误**

基本的单元测试，可以在系统测试之前，把大部分比较低级的错误都消灭掉，减少系统测试过程中的问题，这样也就减少了系统测试中定位和解决问题的时间成本了。

- **找出潜在的 bug**

某些类型的 bug，靠系统测试是很难找到的。例如一些代码分支，平时 99%的场景基本上都走不到，但一旦走到了，如果没有提前测试好，那么可能就是一个灾难。

- **上线前的保证**

加了新代码，上线前跑一把单元测试，都通过，说明代码可能没有影响到之前的逻辑，这样上线也比较放心。如果之前的单元测试跑不过，那么很有可能新的代码有潜在的问题，赶紧修复去吧。

- **重构代码的机会**

写单元测试的过程中，你可能会顺手把一些 code 重构了，为什么？举例，一些长得非常像的代码，如果每次都要写一堆测试代码去测同样的 code，你会不会抓狂？不测吧，覆盖率又上不去，于是我就会想方设法把待测试的 code 改得尽量的精简，重复代码减少，这样覆盖率上去了，测试也好测了，代码也简洁了。如果没有单元测试和覆盖率的要求的话，坦白说可能一来自己不会发现这些重复的 code，另一方面即使发现了，可能也没有太大的动力去改进。

另外，由于单元测试中，你需要尝试去覆盖一些异常分支，这是系统测试常常走不到的地方，于是就会引起你的一些思考，例如这个异常分支是否真的需要？是否真的会发生？对于一些实际上绝对不会出错的函数，那么我觉得可能异常分支是没必要存在的。

- **重新 review 代码的机会**

写 UT 的过程中，我总是会好好看哪些代码执行到了，哪些代码没有执行到，这其实也是一个 review 自己代码的机会，有些时候，并不是 UT 本身帮我找到 bug，而是回头 review 自己代码的时候发现的。

## 36.1.3 单元测试类型

- 基于 API 接口测试（白盒 + 浅度黑盒测试）
- 基于项目代码测试（深度黑盒测试）

## 36.1.4 主流的单元测试库

- `MSTest`（Visual Studio 2019 深度集成，推荐）
- `xUnit`（最流行的库）
- `NUnit`

## 36.1.5 编写测试

### 36.1.5.1 第一个例子

正在编写...

### 36.1.5.2 多行测试数据

### 36.1.5.3 依赖注入测试

## 36.1.6 运行测试

正在编写...

## 36.1.7 导出测试

正在编写...

## 36.1.8 `Assert` 断言

[https://docs.microsoft.com/zh-cn/dotnet/api/microsoft.visualstudio.testtools.unittesting.assert?view=mstest-net-1.3.2](https://docs.microsoft.com/zh-cn/dotnet/api/microsoft.visualstudio.testtools.unittesting.assert?view=mstest-net-1.3.2)

## 36.1.9 反馈与建议

:::note 与我们交流

给 Furion 提 [Issue](https://gitee.com/dotnetchina/Furion/issues/new?issue)。

:::

---

:::note 了解更多

想了解更多 `单元测试` 知识可查阅 [在 .NET 中测试](https://docs.microsoft.com/zh-cn/dotnet/core/testing/) 章节。

:::
